home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Cream of the Crop 26
/
Cream of the Crop 26.iso
/
bbs
/
tftp156.zip
/
TOSSFTP.HST
< prev
next >
Wrap
Text File
|
1997-06-21
|
27KB
|
474 lines
TOSS'in for FTP'in
Copyright(c) 1995, by Lyn Borchert
All Rights Reserved
[ Revision Log ]
01/27/95 - Pre-Release Beta v1.00b
The first beta test version to leave the nest. This one
doesn't do much, just packetizes Areafix and Raid type
messages destine to the uplink node with minimal message
fiddling.
01/29/95 - Pre-Release Beta v1.30b
Spent considerable time developing the Bit manipulation
routines so I could not only read the msg header flags, but
also write them out. There are certain flags that *should* be
toggled off when the message leaves a system. At this point
I'm still not doing that and so far it really doesn't seem to
be causing any problems on the type of messages I've been
tossing. But, now that I'm going to start dealing with host
routed netmail, I suspect I'm gonna have to be more
conforming to the rules. :)
I also spent considerable time working on the NOROUTE: keyword
for the config file. Had to build the routines to read it in,
and then separate out the zone:net/node numbers into a 3
dimentioned array. The really hard part was getting a good
working algorythem for processing these NOROUTE entries. It
was a real brain teaser, but I think the method I ended up
with works very fast and should deal with things correctly.
I did make some assumptions about host routed messages. In
order for TOSSFTP to consider a message to be a host routed
message, several conditions have to be met. I'll list them
below and if there are some host routed messages not getting
routed that you think ought to get routed, you'll need to let
me know. I'll need to get from you, what, if any of the
following conditions was the cause of the failure to toss, why
that is no good for you, and then I'll see if I can't work
around it. Otherwise, it stays as it is.
To be considered a host routed netmail message, the following
conditions must be met and are checked in this order;
1) The message must have the FWD or IN TRANSIT flag turned on.
2) The message must NOT have the Sent flag turned on.
3) The message must NOT have the Hold flag turned on.
4) The message must NOT have the FD DIRECT kludge line.
5) The message must NOT be destine to your Net.
6) Finally, the message must not fail the NOROUTE: checking.
If all these conditions are met, the message will be
packetized and deleted from netmail.
Squashed a nasty bug in the config file reading. TOSSFTP
wasn't ignoring the semi-colon lines. It wasn't a problem as
yet, but could have been a bad problem in a heavily commented
config file.
The toggling off of the handful of flags, will need to be
implimented before another release can be done. Hopefully
I'll take care of that in a day or two. The amount of work
done today warrants an increase in the version number by .30
I've pretty much decided that once the host routing features
have been tested for a few weeks without trouble, I'll release
a "wide beta" copy with a drop dead in it. Not sure how
popular this little utility will be, but the wide beta release
should tell me that over time and at the same time, help to
find any potential problems prior to a normal release.
01/29/95 - Pre-Release Beta v1.40b
This one is now ready for testing I think. TOSSFTP will now
properly set the flags on all messages it packetizes. (fingers
crossed) I haven't done any testing on this yet, so be
careful. Do a "test" run before commiting it to handling the
job for you. (make a backup of your mail before running this
version just incase the uplink refuses it or it packages up
the wrong mail)
If this one works, we are almost ready for a release I think.
Just a little tweeking of the routing stuff might be in order
and I won't know until it's been in use for a while. I think
version 1.50 will be the first official release of the
program.
01/29/95 - Pre-Release Beta v1.41b
Ok, this time I got it for sure! (fingers crossed) Re-hashed
the NOROUTE logic section which was really messed up. Must
not have been thinking too staight when I wrote that section
before. Anyway, the IN TRANSIT bit is no longer looked at,
TOSSFTP doesn't care about it anymore. In it's place now, it
checks for the File Attach bit. File Attach messages are not
allowed to be host routed any more.
Multiple NOROUTE statements are now parsed properly. (previous
release was only parsing the first one) Zone numbers are
still required. (haven't decided how I'm going to deal with
2:* yet, so it's not really a valid NOROUTE arguement)
Due to the method I'm using to create PKT names, I had to
insert a pause during processing of host routed mail. If a
message is determined to be a message that needs to be
packaged up, it will pause for one second after packetizing
the message. PKT filenames are generated based on the number
of seconds since a particular time and without the delay,
TOSSFTP was going so fast that a multiple messages would get
written over top of each other because it was packing 4 to 5
messages a second. That wasn't enough time to let the
filename generator come up with a new filename. So, don't be
concerned if you see TOSSFTP pause for a second, it's supposed
to do that. (but only have tossing an outbound host routed
netmail message)
Added the packet names generated to the log file. Beta
testers should look at these names once in a while and tell me
if they ever see the same PKT name created more than once
during a single run of TOSSPKT. If you see that, it means
that the first message was overwritten by the second message
to generate the same PKT name. It shouldn't ever happen, but
it could and if it does, I need to know about it ASAP so I can
add more code to prevent this from happening again.
02/26/95 - Pre-Release Beta v1.41c
Dog gone it, found yet another problem with the packet naming
process that was causing successive outgoing messages to be
tossed on top of each other. This time I know I fix it for
good!
The release is a bug fix to the EXE file only. Update by
simply overwriting TOSSFTP.EXE with the new one.
Haven't had much time to work on this lately, sorry for such a
delay in getting another release out. I'll try and do better
in the weeks to come. :)
02/26/95 - Pre-Release Beta v1.43
Another Routing Logic Battle has been won! Thanks to Tom
Creek for pointing out a problem with the NOROUTE processing.
This was a pretty subtle problem, so to find it and for
possible future such problems, I've added two new Config
Keywords.
DEBUG:ON | OFF will turn on lots of extra printing during
routed netmail processing. This should make it easy to figure
out just why TOSSFTP isn't packing up a routed Netmail that
you think it should or why it is packing up a routed Netmail
that you think it shouldn't.
DELETE:ON | OFF will cause TOSSFTP to either delete all routed
Netmail messages it packetizes or NOT. If DELETE:OFF is used,
TOSSFTP will simply turn on the SENT flag and leave the *.msg
file alone.
This stuff took me several hours to add and fix, so it seemed
appropriate to jump the revision number up to 1.43 this time.
03/30/95 - Pre-Release Beta v1.44
Improved large .msg handling. TOSSFTP should now skip over
any messages that exceed it's size limits. (I know, .msg
files are not supposed to have a size limit, but for ease of
programming I have set a limit that is more than reasonable)
If a .msg exceeds the limit, TOSSFTP will log that fact and
skip the message instead of hanging your system.
05/30/95 - Pre-Release Beta v1.44 extended
The beta program has been extended with this version. I've
decided to take it another 150 days from today simply because
I've fallen behind in my developement plans. I've just been
too busy at work to devote any time to TOSSFTP these past
couple months. Fortunately, I've received very little mail
from the beta testers, so it would seem that the program is
fairly stable in it's current condition.
06/04/95 - Pre-Release Beta v1.45
Tom Creek found another nasty problem. (notice I'm not
calling it a bug!) It would seem that there are some AreaFix
programs that can create a .msg that allows garbage in the
message header behind the TO: (and other) fields. While this
isn't really against Fido Technical Standards, it is in my
opinion, a very poor programming practice.
According to the FTS, the fields must be NUL terminated. To
me, that means, if you have a 36 character field and you put a
10 character string in that field, the remaining 26 characters
will be NUL. The problem was that some programs where making
the 11th character a NUL and the remaining 25 characters would
be whatever junk was on the hard drive at the time. Not only
does this make more work for TOSSFTP to clean out the junk,
but it makes if very difficult to use a HEX editor/viewer to
find problems with the header structure. It just looks like a
bunch of garbage rather than a nicely formated structure.
Plus, these junk characters are kept by the compression
program whereas 26 nuls will be represented thus causing
better compression of the message.
Granted, these are all minor things, but for systems with
large message traffic, these little things would add up fast.
These are common practices by many C and Pascal programmers
simply because they tend to read and write files once
character at a time rather than the more efficient Block Read
& Write methods. At any rate, with a slight processing speed
reduction, TOSSFTP will now deal message created with these
kinds of practices.
DELETE:OFF enhancement
For those of you who prefer to manually delete sent mail, I've
expanded the delete off feature to include Areafix and Filefix
messages. They will now simply be marked as SENT rather than
deleted and future program runs will skip over any messages
that have the SENT flag on. This behavior is also logged.
New LOGFILE: Keyword (Optional)
By request, you can now tell TOSSFTP where to place it's
logfile and what to name the file. Look at the sample
TOSSFTP.CFG file in this archive for specific instructions on
how to use this new feature. I've made it an optional
keyword. If TOSSFTP does not find this keyword, it will
simply go back to the default of writing TOSSFTP.LOG to the
current directory.
Lastly, I'm changing the method of distribution with this
release. We now have several people running TOSSFTP and as a
result, it's becoming a pain in the butt to send everyone a
file attached E-mail with the new releases. So, I'm now going
to make it available for file request from 1:300/1 at speeds
up to 28.8k. The most recent version will always be available
via the magic name TOSSFTP, 23 hours a day.
One last thing, if you are reporting a problem, please include
a copy of your TOSSFTP.CFG and a clip of your log file that
was created in DEBUG mode showing the error (or not if it
didn't register). Send them to 1:300/12 or you can E-mail
them to lynb@primenet.com. Keep in mind that I only check
E-mail a couple times a week, but Netmail on 300/12 is seen
several times a day.
08/18/95 - First Full Release v1.50
Minor bug fix. TOSSFTP should now handle *.msg files named
with numbers higher than 32,000. Who would have ever thought
someone would have more than 32,000 *.msg files in their
netmail directory. :)
New feature suggested by Tom Creek. Errorlevel Setting.
TOSSFTP will now set an exit errorlevel of either 0 or 1
depending on whether it did any tossing or not. An errorlevel
of 0 means it did NOT toss any *.msg or echomail bundles. An
errorlevel of 1 indicates that something got tossed. Thanks
Tom.
Documentation re-write. With this being a full release the
docs now contain all the license and disclaimer information.
Please read through this stuff. (at least once) Just so you
know where you and I stand. This version is the first to not
contain a "drop dead date" embedded in it. Instead it will
start beeping and pausing after a 30 day evaluation period
unless there is a valid serial number in the config file.
11/04/95 - Bug Release v1.54
Fixed a few problems as follows.
Tom Creek reported that the errorlevel setting was only
happening if we tossed host routed netmail and not when the
program only tossed an echomail bundle or two. I decided to
fix and enhance this a bit. With this version, if an echomail
bundle was tossed, the errorlevel will be set to 1. If a host
routed netmail message is tossed the errorlevel will be set to
2. And if both operations take place the errorlevel will be
set to 3.
Another bug caught by myself first and reported by a couple
others was that TossFTP would frequently not toss some routed
netmail until a second or third run of the program. Instead
it would simply report the message destination and then go on
to the next message. This was really a very difficult bug to
trace down, but trace it down I did. To be breif, the problem
was the result of the variable containing the AreaMgr's
Destination address being trampled with the address of the
most recently tossed message. The result was the first routed
netmail message encounted was tossed correctly and none after
that. Echomail bundles were not affected by this. It's now
fixed.
Yet another suggestion by Tom Creek. (I may have to give him
some money for all his assistance here) It seems that TossFTP
didn't care what was in the outbound directory. Normally not
a problem, but if you had copied an echomail bundle over
manually and manually truncated the source file and FORGOT to
delete the file attach message... The next run of TossFTP
would (you guessed it) copy the zero length file over top of
the file in the outbound directory. Affectively and
irreversably deleting that outbound mail. For safety's sake,
TossFTP now checks for the existance of the destination file
before doing a copy and if it exists it exits the program
immediately with an errorlevel to denote the cause of the
problem. It does not continue processing the rest of the
mail.
File Sharing has been added. I've added the code necessary
to get along with other multi-user software. This is not
fully implimented in this release, but TossFTP will now
correctly "share" and "lock" files that it is making use of.
If it is unable to get a lock on a file, it will still
generate an error and skip to processing the next message. In
the future, I may make it continue to attempt to get the file
lock. Right now, I don't think that is such a good idea
because it could cause TossFTP to end up in a continous loop.
I still maintain that if you operate in a multi-node
environment that you MUST take down all nodes that would have
anything to do with your *.msg directory when running TossFTP.
This is the ONLY way to be sure the messages don't get
renumbered in the middle of a TossFTP session (which would
cause extreme damage) and it's the only way to be sure no
other program has a message file locked preventing TossFTP
from working on it.
Lastly, for this release, I've re-written the error-trapping
code. Included in the archive is a file called ERR.TXT which
contains all the errorlevels that could be set by TossFTP
based on certain conditions. Basically, you can consider any
errorlevel between 100 and 255 as a fatal error. There are
some errors that are higher than 200, but they are very
unlikely to ever happen. In this version, TossFTP will
continue processing even though a fatal error was encountered.
This is a potentially dangerous situation, however, it should
not cause any damage other than to possibily to the message
that caused the error in the first place.
11/04/95 - Interium Release v1.55
It appears that some mail tossers are very nit-picky about
short packets. A "short" packet is a PKT that doesn't have a
PKT termination character ending it. In my opinion, this
should not be a "fatal" error causing stopage of mail
delivery. Afterall, the format of the message inside the PKT
is correct and complete, the PKT header is correct and
complete. If the tosser gets to the end of the PKT without
experiencing any errors in format of the messages processed so
far, why not just stop processing? At most maybe write to the
log that the PKT ended without a PKT terminator, but still
process the PKT and deliver the mail. Apparently, there are
some tossers that treat this as bad mail and refuse to deliver
the mail when there is only one NUL ending a PKT instead of 3
NULs. As a result, this version of TOSSFTP will now create
PKT files with the 3 NULs ending the file. Hope it doesn't
break anything else. :)
During this quick release I also took the time to add a
command line argument. For those of you who have more than
one DEST system, you can now place the full path and filename
of the *.CFG file you wish TOSSFTP to use. If no command line
arguement is found, the default of TOSSFTP.CFG will be used.
If the alternate *.CFG file is in the current directory, you
don't need to specify the path to it. Examples Follow;
C:\TFTP\> TOSSFTP
Uses TOSSFTP.CFG located in the current directory
C:\TFTP\> TOSSFTP c:\mail\toss2.cfg
Uses TOSS2.CFG located in the c:\mail directory
C:\TFTP\> TOSSFTP toss3.cfg
Uses TOSS3.CFG located in the current directory
The purpose of this addition is to allow systems to run
TOSSFTP multiple times with different config files in order to
toss mail to different uplink systems. It's not likely that
TOSSFTP will in the future have the ability to have one config
file reflect multiple uplink systems in order to process all
systems in one pass. The main reason is because virtually
everything in the CFG file would have to be duplicate'able.
Since TOSSFTP doesn't really take all that long to do it's
thing and using multiple CFG files will accomplish the same
task, I'm not convienced it's worth my effort to support
multiple DEST nodes in one CFG file. Maybe in the future I'll
decide differently, but for now this will have to do.
Finally, I did some tweeking of the status bar that displays
during *.MSG gathering and sorting. It should look nicer on
systems running FAST machines with large numbers of Netmail
messages. The only purpose for this thing is so you can tell
whether TOSSFTP is actually still doing something or is hung.
When you have several hundred Netmail messages for TOSSFTP to
scan and sort, it can take several seconds to do it. In the
past, it would look like TOSSFTP was hung while this
processing took place, so I added this little ditty to
indicate processing was still going on. It adds a very small
amount of overhead to the sorting, but I think it was worth
the sacrifice. (Keeps my heart from stopping anyway)
There you have it, for the New Year. I seriously don't intend
to release any new versions in 1996 unless something drastic
happens. The next real release will be a substantially
different program implimenting several rather major changes to
TOSSFTP. At that time, I will probably make a feature-less,
free to use version and slightly increase the registration for
the new release. Whether I ask current registered users to
kick in some more dollars for the new release is not decided
and I don't expect to decide til I see the end results of my
labors. At worst, they may have to pay an upgrade fee that
will be less than new user registration. But it will be worth
it.
Some of the things I'm interested in doing to TOSSFTP are;
Make it Zone Aware
Totally re-vamp Routing control
Selective PKT Types
Support for Non-Echomail OUTBOUND File Attaches
Improved processing speed
Support for a SQUISH Netmail File
FD & IM Semaphore Support
Support for Other Mailers
Improved Multi-Node Operation
Direct Comm & FTP via PPP/SLIP implimentation making
TOSSFTP the only program you need to connect and
send/receive your files.
The last one there is a BIG if, but none the less, it's
something I'm interested in doing.
Have a GREAT 1996 guys and gals.
06/20/97 - Update Release v1.56
Wow, has it really been almost a year and a half? Well, 1996
was a holiday year for me. You will all be happy to know I've
started work on v2.00. I did decide to create a new
configuration program and data file. It does support multiple
destinations and is nearly complete. After that I'll start on
the revisions to the actual tossing program. With some luck
we might see v2.00 round the first of 1998.
For this release, I did some cleaning up of the niffty little
status bar. It should work much better. I know I keep saying
that, but I'll get it one of these times. I corrected some
spelling errors that have been pointed out by users.
I'm also dropping out of national echomail distribution, so I
won't be able to read the FTPHUB echo anymore. I needed to
get a new release with revised contact information in the
documentation and wanted to do so before my access was
terminated.
My BBS will remain alive and a member of Fido. 1:300/12 So
you can still reach me via Netmail at that address. I'm also
on the net with a perminent E-Mail address of
lyn.borchert@usa.net
The latest version of TossFTP can be gotten from my website
currently http://www.dakotacom.net/~lynbor and soon there
will be a mailing list you can join to get support as well as
future release information. More on that later. The website
is probably the most "if'y thing" since it's address changes
if I change my internet service provider. I'm sure George
Peace will continue to keep a recent copy available at his FTP
site and Mike Jordan's site at ftp.europa.com in
/outgoing/tossftp/
